update queries with sql in materialized view #418
Conversation
There was a problem hiding this comment.
Instead of writing the entire materialized view SQL query in the docstring of the functions, let's create a document elsewhere and point to it in the docstring. This'll clean up the docstrings (which are what is shown when you hover over a function in VSCode or whatever else) and means that we don't have to change the query documentation in two places if the materialized view code changes.
Ideally, we wouldn't write the materialized view code in here at all, and instead point to a place where it can be read that updates automatically if the SQL gets rewritten by Sean at some point (so we don't have to come back into our repo and manually update the text)
|
@JamesKunstle Im not too familiar with how materialized views work on if there is a way to "read" a materialized view. Ill noodle on where we can put the current sql write out and talk to sean about the possibility of "reading" the materialized view once we get past this current set of augur fixes |
|
@JamesKunstle Maybe we can add a materialized view section on the read me? Im struggling to find a good place for this but def think its important bc if anyone is hosting their own instance they will need that info |
|
@sgoggins just to confirm, materialized views are unique to a single db? |
|
@cdolfi I'd write the query as a .sql document in the 8Knot/docs folder and put a reference to that file in the company and contributors function docstrings. |
cdolfi
force-pushed
the
query_doc_update
branch
from
9e88997
to
bca0c23
Compare
|
@JamesKunstle great ideas, implemented it. This is ready for review again |
This adds the sql query for materialized view in comments